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Abstract —The Grid and Cloud User Support Environment 
(gUSE) enables users convenient and easy access to grid 
and cloud infrastructures by providing a general purpose, 
workflow-oriented graphical user interface to create and run 
workflows on various Distributed Computing Infrastructures 
(DCIs). Its arrangements for creating and modifying existing 
workflows are, however, non-intuitive and cumbersome due 
to the technologies and architecture employed by gUSE. In 
this paper, we outline the first integrated web-based workflow 
editor for gUSE with the aim of improving the user experience 
for those with industrial data workflows and the wider gUSE 
community. We report initial assessments of the editor’s utility 
based on users’ feedback. We argue that combining access to 
diverse scalable resources with improved workflow creation 
tools is important for all big data applications and research 
infrastructures. 
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1. Introduction 

A plethora of mature workflow systems has evolved that 
support diverse workflow concepts and workflow languages 
with different strengths and focus on different areas of work- 
flow processing. As well as requiring appropriate workflow 
concepts for their applications, a user community has to 
evaluate four other requirements: a) its usability for all 
members of their community in their work context; b) its 
availability, with respect to licensing terms and cost; c) its 
anticipated long-term support, e.g. via an active open-source 
community; and d) its ability to deal efficiently with the 
scales of data, computation and concurrent use required. 

The majority of users in the context of the project VAVID 
m have no previous exposure to the kind of HPC systems 
used to power big data analysis. Consequently, the main 
preference regarding usability has been for a web-based 
graphical user interface enabling intuitive creation, editing, 
submission and monitoring of workflows without the need 
for programming or installations on the users’ side. The 
aspects of scale most critical in the VAVID project are 
large amounts of data to be processed and a requirement 
to access high-performance computing infrastructures. The 
third aspect has been that it should be free of charge also for 
companies since the project partners are partly from industry. 
Last but not least, a robust security concept is paramount 
given the sensitive nature of the industrial data. 


gUSE with its flexible web-based user interface WS- 
PGRADE consists of web services for the workflow manage¬ 
ment exploiting local clusters as well as diverse distributed, 
grid and cloud infrastructures via the “DCI bridge” 12 and 
accessing various distributed data systems via the “Data 
Avenue” in. With these mappings to diverse computing 
resources and as open source software, gUSE fulfllls the 
requirements for the second, third and fourth criteria for 
the selection of a workflow system. The usability of WS- 
PGRADE has been found sufficient except for the process 
of creating workflows. 

With the WS-PGRADE system prior to the work reported 
here, users had to create workflows in three stages, one 
of which required the use a particular graph editor. This 
editor is a Java Web Start application and therefore requires 
a local installation of Java and its security preferences to 
be set correctly; the latter being quite inconvenient for the 
users particularly within industrial and organizational con¬ 
texts. Eor example, conflicts with an organization’s security 
management policies or restrictions on downloads and self- 
administered installations will often inhibit the use of the 
gUse workflow editor in such contexts. 

The three-stage creation process also impeded experiment 
and innovation by requiring completion of one aspect, the 
topology of data and control flow, for every step of a 
workflow, before the details of individual steps could be 
considered. Whereas, a scientist or engineer may want 
to reflne some parts before outlining others, or be able 
to modify the workflow’s graphical representation after a 
workflow has been created. Both are important in R&D 
contexts epitomized by VAVID, as the practitioners need to 
fluently innovate, reflne methods formalized as workflows, 
incrementally develop workflows and repeatedly use existing 
workflows on new data or with new parameters—a modus 
operandi well supported by science gateways ISll . 

Therefore, the usability issues surrounding gUSEAVS- 
PGRADE the graph editor, the three-stage workflow cre¬ 
ation process and the ability to incrementally develop and 
reflne workflows have been addressed and replaced by the 
workflow editor presented in this paper. This allows domain 
scientists to focus and take more responsibility of their own 
work rather than the technical aspects surrounding it. While 


this editor is specific to gUSEAVS-PGRADE, it is a step 
in the direction of also empowering scientists and engi¬ 
neers, improving their prototyping agility and reducing their 
dependence on IT specialists during innovation ( 61 . When 
methods have stabilized and are being used in large scale 
production the IT specialists may still contribute efficiency 
and reliability improvements. 

The paper establishes the background, and presents the 
design and implementation of the new editor in that context. 
An initial evaluation is then reported, that leads to conclu¬ 
sions and plans for further work. 

II. Related Work 

Developers and providers of workflow management sys¬ 
tems have recognized the demand by user communities for 
usability during the composition of workfiows, i.e. their 
initial creation and their subsequent edits to improve the 
method or develop a derived method. WS-PGRADE (Tl, 
Pegasus O, KNIME (91, Galaxy lITOl . Tavema Ull, Kepler 
113, Swift ms and UNICORE f\M are widely used open- 
source workfiow management systems, which offer work- 
fiow canvases. Workfiows are illustrated as directed graphs 
on the canvases. Nodes normally represent jobs or executable 
modules, while the directed edges define the control and data 
dependencies between the jobs. 

Conceptually WS-PGRADE distinguishes between an ab¬ 
stract workfiow and a concrete workfiow. The abstract 
workfiow is created via the graph editor with drag-and-drop 
mechanisms to add nodes and connect them to each other via 
input and output ports representing the data flow. The result 
is a graphical representation of the workfiow lacking the 
information about distinctive jobs or data. In a further step, 
the abstract workfiow is extended to a concrete workfiow, 
which can be configured for concrete jobs, parameters and 
data files. Similar to gUSE, Pegasus supports a wide range 
of cluster, grid and cloud infrastructures with cutting-edge 
data management capabilities. Its web-based user interface 
is formed by Triana ca but only exists as a prototype. 

KNIME follows a different approach to the workfiow 
canvas than WS-PGRADE, that its users find convenient and 
intuitive. Users select from available modules and nodes that 
they want to connect with each other. They can develop 
parts of a workfiow completely, including running that 
subgraph and inspecting intermediate data, before extending 
the workfiow towards completion. This allows their focus 
to match the way they think about a method. Advanced 
users can also create new modules, which requires some 
programming experience. 

The KNIME workfiow canvas is very intuitive but is of¬ 
fered as a workbench based on Eclipse requiring installation 
on the users’ side and not as web-based user interface. This 
detracts from its utility in contexts such as VAVID. Galaxy 
follows a concept for creating workfiows similar to the one 
in KNIME and offers a toolbox via a web-based solution. 


While Galaxy is widely used, especially by the biomedical 
community, the data management capabilities are quite re¬ 
stricted for large data and necessitate data transfers between 
single jobs of a workfiow to the server hosting the back¬ 
end of Galaxy. However, Galaxy can map to the highly 
parallelized enactments of Swift ca. Another workfiow 
system well established in the biomedical community is 
Taverna but the workfiow canvas is only available as a 
workbench. The workfiows can be shared via the social 
website my Experiment El. 

Kepler offers a desktop application and a web-based 
graphical user interface for workfiow management. The 
latter has fewer features than the desktop solution and lacks 
support for creating or modifying a workfiow’s structure. 
Thus, it cannot be used for composing a workfiow, but 
only for uploading existing workfiows, which can then be 
modified only with respect to the data and parameters used. 
While UNICORE also provides both solutions for workfiow 
management and the web-based one is capable of all features 
available in the desktop application, its use is restricted to 
computing infrastructures interfaced via UNICORE. 

Commercial products offering workfiow canvases include 
a commercial version of KNIME, products applying WS- 
BPEL (Web Services Business Process Execution Language) 
ca, PipelinePilot HU or the Genomics Research Platform 
created by OnRamp (201. The commercial version of KN¬ 
IME supports advanced features for increasing productivity 
such as connectors to clouds and Software-as-a-Service 
(SaaS) as well as features for collaboration. 

WS-BPEL is widely used in industry but requires that 
all applications integrated into a workfiow are available 
as web service. PipelinePilot, as well the the Genomics 
Research Platform are solutions that are especially tuned 
for bioinformatic applications but general applicable for 
diverse domains. Workfiows can be configured for local and 
batch systems but are missing connectors to grid or cloud 
infrastructures. Since partners in the VAVID project are 
from industry, the business models behind such commercial 
solutions would necessitate the coverage of license costs 
without delivering more functionalities than gUSE. 

In summary, few workfiow systems deliver the power of 
diverse digital resources as gUSE does and most of the 
web-based creation and editing tools either require local 
software installations with inherent security problems or 
offer incomplete functionality. Hence we suggested a general 
approach to these deficiencies (H, however, the current 
work, though a step in that direction, is specific to gUSE. 

HI. Designing the Workflow Editor 

In this section, we first give an overview of the 
pre-existing workfiow editing capabilities of gUSEAVS- 
PGRADE and detail its associated problems. We then 
introduce a partial solution that was under development 
before discussing the design of our new web-based workfiow 


editor. We explain how it overcomes the aforementioned 
inconveniences and how it is integrated into gUSEAVS- 
PGRADE. 

A. gUSE/WS-PGRADE Graph and Workflow Creation 

gUSEAVS-PGRADE is composed of a number of Liferay 
portlets each providing a specific functionality in relation 
to workflow management. These portlets are typically com¬ 
posed of a presentation layer, portlet layer and persistence 
layer. The portlet content is displayed using Java Server 
Pages (JSP), with optional imported JavaScript libraries, 
where the portlet layer interacts with the client-side presen¬ 
tation layer to serve resources or perform defined actions 
dependent on the actions of a user. If necessary, the portlet 
will interact with the database to store or retrieve data. 

Using the pre-existing facilities to create a gUSEAVS- 
PGRADE workfiow a user must navigate through three 
portlets: Graph, Create Concrete and Concrete. A work¬ 
fiow’s graph, or an abstract workfiow, is created by down¬ 
loading and executing a Java Network Launch Protocol 
(JNLP) file from the Graph portlet. This instantiates the 
Java Web Start (JWS) graph editor application, only after 
the user has correctly added a Java security exception. This 
process is not user friendly and many problems can arise 
if the correct security exception is not added or there are 
problems with the local Java installation. Eigure 1 shows an 
example graph created using the JWS graph editor. 
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Figure 1. gUSE Java Web Start Graph Editor 

Users have the ability to add and remove jobs, input and 
output ports as well as the connections between ports, all of 
which are represented as an XML document. After the graph 
has been saved, it is stored in the gUSE database. Graphs can 
then be transformed into workfiows via the Create Concrete 
portlet and configured using the Concrete portlet. The latter 
displays a static image of the workfiow graph where jobs can 
be selected allowing configuration parameters to be entered 
via a pop-up form, e.g. defining a job’s executable type, its 
arguments and data files. Although configuration changes 


can be made to an existing workfiow, the graph’s topology 
and geometry cannot be modified. Therefore, when a user 
wishes to make such changes, a new graph and workfiow 
must be created and re-configured. 

B. A Web-based Workflow Editor for gUSE/WS-PGRADE 

We first introduce a graph editor that was being developed 
contemporaneously, which fed into our design, and then 
explain the design of our workflow editor. 

1) Graph Editor: Our workfiow editor builds on the pre¬ 
vious work of the National Institute of Astrophysics (INAE|^ 
that created a web-based graph editor portlet implementation 
of the JWS graph editor, named GraphEditorPortlet. The 
graph editor was developed in the context of the VisIVO 
mobile application IJU to allow gUSEAVS-PGRADE usage 
from mobile devices, where the JWS editor application 
cannot operate. The web-based graph editor was developed 
using the JavaScript libraries KinecticJS 4.7.^ jQuery 1.9 
and jQuery UI 1.10.^ and replicates the JWS graph editor 
both in terms of functionality and presentation. Therefore 
any user familiar with the current JWS graph editor of 
gUSEAVS-PGRADE will be able to easily use the web- 
based graph editor. 

The web-based graph editor is split into two components: 
the graphical editor front-end and the back-end Liferay 
portlet implementation. Much of the editor’s complexity 
resides with the former, where the position of graphical 
objects and their respective states must conform to the user’s 
requirements. An object’s state consists of the object name, 
description and its vy coordinates. If an object is a port, the 
port type, its sequence number and a list of any connections 
to other ports are included. 

The front-end also provides dialogs, similar to those of 
the JWS graph editor, which must initiate the appropriate 
operations such as saving and loading graphical representa¬ 
tions. Save operations convert each object’s state into XML, 
using the XMLWriter librar}j^ to create an XML document 
that is passed to the portlet via an AJAX call. The XML is 
then sent to the gUSE wfs module via existing mechanisms 
to store the graph as an abstract workfiow in the gUSE 
database. Similarly, a load operation retrieves the required 
graph’s XML from wfs, which is then passed to KineticJS 
to reconstruct each object’s state on the display canvas. 

This web-based graph editor is a direct replacement for 
the current gUSE JWS graph editor. It does not allow graphs 
of existing workfiows to be modified, nor does it remove the 
inefficient three-stage process of creating, configuring and 
submitting workfiows. 

1 www.inaf.it/en 

2 www.kineticis.com 

- www.jquery.com 

^www.javascriptsource.com/ajax/xmlwriter.htm 
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Figure 2. The Web-based gUSE Workflow Editor 


2) Workflow Editor: In order to transition from a graph 
to workflow editor and to solve these usability issues, we 
developed a new portlet named the WorkflowEditorPortlet, 
which inherits from both the GraphEditorPortlet and the 
Concrete portlet but contains additional functionality and 
improvements to allow the user to directly interact with 
workflows as opposed to just graphs. The only common 
entity between the graph and workflow editor is that of the 
interface and its associated code. Improvements to both the 
front-end and back-end graph editor components, as well as 
the necessary additions to gUse, are the foundations of the 
workflow editor. Figure 2 gives a preview of this complete 
workflow editor. 

We see that users have the necessary functionality to 
create, save and load workflows. Furthermore, users have 
the ability to operate the editor in two modes: graph or 
workflow. The former mode is an improved version of the 
web-based graph editor inherited from INAF, while the latter 
mode allows direct interactions with workflows, including 
those created by the JWS graph editor, as well as the ability 
to submit syntactically correct workflows to a conflgured 
DCI. The differentiation of modes ensures past and present 
users of gUSEAVS-PGRADE are still able to operate on 
graphs and workflows as individual entities. 

In addition to creating this new portlet, we have modifled 
the existing gUSEAVS-PGRADE Concrete portlet to exhibit 
equal functionality to that of the WorkflowEditorPortlet by 
modifying the former’s conflgure.jsp presentation layer to 
include our editor in place of the static workflow image 
previously provided. In order to ensure both the Work¬ 
flowEditorPortlet and the Concrete portlet provide consistent 
functionality, both share the same presentation layer, as 
shown in Eigure 3 depicting the editor’s architecture. 

In effect, our WorkflowEditorPortlet replaces the 
gUSEAVS-PGRADE Concrete portlet, but with added 
functionality. The availability of latter remains at the 
discretion of gUSE. Eigure 3 also shows that conflgure.jsp 
includes the JSP flies related to the selected operating mode. 
Regardless of the mode selected, users continue to interact 
with the same KineticJS objects, however the integration of 
workflow editing capabilities required substantial changes 
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Figure 3. Workflow Editor Architecture 


to both the graph editor and the gUSE back-end; a task that 
proved difficult when integrating a solution into a system 
adopting legacy libraries and where the distinction between 
front-end and back-end functionality was minimal. 

A large number of these modiflcations were made to allow 
graphs of existing workflows to be altered on-demand. The 
previous implementation of gUSEAVS-PGRADE lacks the 
functionality to save incremental changes to a workflow’s 
graph and instead only permits the bulk saving of graphs 
and workflows to the database. This is a result of storage 
mechanisms, which cache loaded workflows and only allow 
conflguration parameters to be added or modifled. Upon a 
save operation, the cache contents are saved to the database, 
in turn saving any conflguration changes, however any 
modiflcations to the graph are not replicated in the cache 
and therefore are not saved. 

We upgraded the cache to account for such changes by 
creating and instantiating a j Query AJAX call for each 
type of change made to the graph. The change is caught 
and processed by the portlet which is then passed to the 
appropriate handler to update the cache. This process, as 
well as the available handlers, are shown in Eigure 3. 








































































For example, upon the addition of a new port, the presen¬ 
tation layer concatenates the values of the port’s properties 
into a string and an AJAX call is made. The portlet processes 
this call and spawns the AddPort handler, which enters 
the values directly into the cache, either for a new or 
an existing workflow; the latter resulting in current values 
being overwritten. The properties of an existing port can be 
amended via the ChangePortConfig handler. The amended 
cache, present in the Java class UserData, can then be stored 
into the database when a save operation is initiated by the 
user. 

The close conceptual relationship between a gUSE graph 
and workflow means that in order to allow the user to 
directly store workflows, it first must be saved as a graph. 
The workflow can then be created from the graph by calling 
the existing method newWorkflow, which takes the graph 
name as one of many arguments, and saves the workflow in 
the database. Similarly, workflows are loaded by determining 
the graph name of a specified workflow and returning the 
graph’s XML to reconstruct each object’s state on the display 
canvas. 

The modification of the gUSE cache appears as a triv¬ 
ial addition, however this introduced many complications. 
Eirstly, a new series of database interactions had to be 
created to retrieve unique identifiers for each new workflow 
object added to the display canvas. Secondly, any object 
added to the canvas had to be checked for uniqueness and 
correctness; a feature that was not present in the inherited 
web-based graph editor. Eor example, by adding a port, 
its name and sequence number must be compared with all 
others attached to the job. 

Validity checks must also ensure objects and their state 
are consistent with a correctly constructed workflow. Eor 
example, validity rules must ensure an output port cannot 
be connected to another output port. Thirdly, and most 
importantly, the workflow’s state present in the cache must 
be equivalent to the state present on the display canvas; a 
feature also not present in the inherited web-based graph ed¬ 
itor. If the state is not equivalent in both entities, workflows 
will be incorrectly configured and subsequently, are likely 
to exhibit unexpected behaviour when executing on a DCI. 

The ability to dynamically add jobs, ports and connections 
to the cache also allows on-demand workflow configuration. 
Previously, users had to create and save a workflow before 
it could be configured via the Concrete portlet, by selecting 
jobs from the static representation of the workflow. By 
selecting the desired job, users can now instantly add con¬ 
figuration parameters without having to save the workflow 
in the first instance; all changes are reflected in the cache 
and are uploaded to the database when the user initiates a 
save operation. 

The incorporation of this feature came with many dif¬ 
ficulties, primarily due to the incompatibilities between the 
different j Query versions used by the web-based graph editor 


and the gUSEAVS-PGRADE workflow configuration entry 
form. The latter uses jQuery 1.3.2 and outdated associ¬ 
ated j Query libraries such as jqDock and Beauty Tips. In 
order to upgrade these libraries, a complete re-design of 
the gUSEAVS-PGRADE elements reliant on these libraries 
would have to take place. As the inherited web-based editor 
is only compatible with jQuery versions 1.9 and above, a 
solution was devised to operate multiple jQuery versions 
concurrently. 

The web-based workflow editor provides a much needed 
solution for the workflow community, and in particular for 
those who interact with and submit workflows via gUSE. 
We have shown the necessary changes to create a simple 
yet effective web-based editor, removing the dependency for 
a client-side Java installation and extending the Java server 
portlet implementation. Eurthermore, by using standard web 
technologies, the editor operates on all popular web browsers 
allowing all users to efficiently create workflows and modify 
existing ones. 

IV. Evaluation 

The new editor and its integrated method for workflow 
creation and management have been deployed and evaluated 
on one of the test systems used for the VAVID project; 
detailed functionality and performance testing of the editor 
will take place after the use cases of VAVID have been fully 
created. 

When opening the workflow editor portlet, as expected, 
no Java Web Start application is instantiated and the editor 
is now displayed inside the web browser. As there is no 
separate editor window, the editor now follows the same 
style conventions used in the rest of WS-PGRADE. Eurther¬ 
more, it is also much faster and involves less user-interaction 
than downloading and opening the former editor. The former 
method was also cumbersome, often involving having to 
determine how to enable Java support in the web browser 
and properly adjust the security settings of Java to execute 
the editor. 

The new editor improves the usability in different scenar¬ 
ios as well. One of them being the ability to use test systems 
located behind a remote firewall by simply tunnelling the 
HTTP port using SSH and accessing the localhost with the 
browser. Eor users without previous exposure to gUSE, the 
new integrated method of workflow creation, configuration 
and submission within the same portlet is more intuitive 
than the previous three-stage method. These improvements 
translate into less helpdesk support required by end users and 
thus, more time for the development and integration teams 
to concentrate on other aspects of the VAVID project. 

While the general idea of simplifying the three stages of 
workflow management into a single one is perceived as being 
more intuitive by the users, the current way of configuring 
jobs with the new editor could be further improved. Once the 
workflow graph is created, users can modify the name and 



description of each job by double-clicking on it. However, 
selecting any other point of the node that is not its name 
will display the configuration dialog for the corresponding 
job. This behaviour is hinted to the user by highlighting 
the job’s name on mouse over. Our experience shows this 
isn’t sufficiently clear for most users independent of their 
experience level, therefore this will be revised in future 
versions. 

Other potential improvements could be made to the 
accessibility and positioning of the workfiow nodes. The 
accessibility problems relate to the color-scheme and style 
used to render workflows, making certain selections and 
active elements difficult to recognize. This is simple to 
resolve and will be fixed in future releases. The subop- 
timal positioning of the elements can be traced back to 
the JavaScript frameworks upon which the editor is based. 
Despite being state of the art when the original INAF- 
implementation of the editor was created, they have now 
been superseded by more powerful ones. Reimplementing 
the editor with a new framework would have required an 
effort outside the means of the VAVID project. 

An important requirement for the new editor is that 
of backward compatibility with workflows created using 
former versions of the editor. In addition to VAVID’s own 
workflows, the gUSE development team provided a set of 
test workflows to evaluate the backward compatibility. No 
compatibility problems have been found during our tests. 
Previous workfiows could be loaded, modified and submitted 
by the new editor. Moreover, given that the underlying for¬ 
mat in which the workfiows are stored in the database hasn’t 
changed, compatibility issues are not expected. Another vital 
compatibility aspect is a consistent rendering and function¬ 
ing of the editor across different browsers and platforms. 
During the development and evaluation of the editor, current 
versions of Mozilla Firefox, Google Chrome, and Safari 
were used on Linux, OS X, and Microsoft Windows without 
observing any major changes of the HTML-rendering or a 
reduction in usability. 

Finally, the installation procedure and accompanying doc¬ 
umentation of the new editor were also evaluated. Installing 
or updating the editor from the source code involves the 
compilation and re-deployment of the gUSE frontendbase, 
wfs, and wspgrade modules. In our experience of using 
gUSE 3.6.8, this can be performed with little effort by 
following the installation instructions, if there is a working 
Java SDK and Apache Maven installed on the system. It 
is our hope that the new editor will be integrated into 
future releases of gUSE making the manual installation 
unnecessary. 

V. Conclusion and Outlook 

In this paper, we have outlined an improved workfiow 
editor for gUSEAVS-PGRADE that replaces the three-stage 
process of creating, configuring and submitting workfiows. 


which was unnecessarily cumbersome for prototyping pro¬ 
cessing and analysis methods and raised conflicts with 
security policies. Our web-based workfiow editor portlet 
implementation directly replaces the gUSE Java Web Start 
graph editor application and subsequently, the requirement 
of a local Java installation and correctly specified security 
preferences. The previous three-stage process of creating 
workfiows has been reduced to a single stage process allow¬ 
ing workfiow creation, instant configuration and submission 
all within our workfiow editor portlet. 

Furthermore, users now have the ability to dynamically 
modify the graphical structure of their existing workfiows 
and update job configuration parameters on-demand, allow¬ 
ing the incremental development and refinement of work¬ 
fiows; a feature supported by many other science gateways 
and a requirement from the users of the VAVID project and 
many other communities. 

We believe that the aforementioned improvements to the 
gUSEAVS-PGRADE workfiow creation process will greatly 
enhance the user experience of interacting with workfiows 
allowing domain scientists to focus and take more respon¬ 
sibility of their own work rather than the technical aspects 
surrounding it. Preliminary usability studies strongly support 
this. However there are many improvements that could 
be made to gUSE and to our web-based workfiow editor 
to improve the users’ experience and operational behavior 
further. 

The revision of the system’s architecture to make the 
client-side (browser embedded) and server-side of gUSE and 
WS-PGRADE more independent would be a first step. The 
API presented by the server side should support both bulk 
and incremental changes to workfiows. This might be parti¬ 
tioned across several back-end micro-services with sharply 
focused functionality to improve flexibility and maintainabil¬ 
ity 1^ . These stable and relevant interfaces would support 
incremental enhancements to these adopted web-based tools 
and permit others to create advanced alternatives. 

Such workfiow editors would exploit novel JavaScript 
libraries and agile web frameworks. For example, the 
JavaScript library jsPlumt|^ would improve the visual rep¬ 
resentation and deliver ready made graphical interaction 
modes because of its excellent design. It offers many fea¬ 
tures for diverse illustration, representation and manipulation 
models for the nodes and edges of a workfiow graph. Also, 
it is developed by an extensive open-source community, 
thereby relieving the workfiow-editor developers from sub¬ 
stantial responsibilities. 

The workfiow editor reported here does not use this 
yet for pragmatic and historical reasons—its adoption is 
anticipated. It underpinned the prototype generic workfiow 
editor reported by Gesing et al. That proposed web- 
based workfiow editor is intended to accommodate multiple 

“ www.jsplumb.org 


workflow systems for the following reasons: a) develop¬ 
ing powerful and easily learnt web-based GUIs that run 
on all devices from handhelds to work stations demands 
skills and effort best amortized over many communities 
and the similarities between workflow systems make this 
feasible; b) user communities have considerable investments 
in particular workflow systems that make transfer to re¬ 
placement workflow systems infeasible, consequently when 
inter-disciplinary work develops across communities using 
different systems, and when researchers transfer between 
groups that consistency saves the researchers intellectual 
hurdles and delays; and c) the workflow enactment systems 
are already developing capabilities for integrated multi¬ 
workflow language enactments, e.g. 12^ . and at present 
developers of the scientiflc methods have to use each native 
workflow editor rather than being able to work on the whole 
method. 

A long-term campaign is required to improve the usability 
and abstraction so that users who are not adept at computing 
can nevertheless take full responsibility for the logic of their 
own methods and can innovate and experiment freely. This 
becomes ever more necessary as the wealth of available data 
grows and as more-and-more domain expect to exploit its 
potential. A broad collaboration across disciplines should 
address this agenda. 
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